【レポート】RDBMS だけで本当にいいの？ NoSQL on AWS の勘所 #AWSSummit

AWS Summit Tokyo 2018

#Amazon Neptune

#イベントレポート

#Amazon ElastiCache

#Amazon DynamoDB

#NoSQL

吉江健斗

2018.06.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

登壇者

アマゾンウェブサービスジャパン株式会社技術統括本部ソリューションアーキテクト桑野章弘

アジェンダ

本セッションの目的
よくある話
NoSQL
AWSのNoSQLサービス
NoSQLユースケース
NoSQLのデザインパターンの考え方

本セッションの目的

NoSQLの活用方法を知り、より良いシステムを目指す！

よくある話

よくある話としてNoSQLを使うにあたり、以下のような話が出てくる

「特にRDBMSで困ってないし使う必要がないのでは？」
「使ってみたけど運用大変だし、逆に性能悪くなったよ。」
「そもそもNoSQLってどういうときに使うの？」

NoSQLとは

RDS	NoSQL	備考
ストレージに最適化	計算リソースに最適化
正規化/リレーショナル	非正規化/階層構造	目的を達成させるためにどのような階層にするかをフォーカスする必要がある
SQLを使用	各データベースによって異なるクエリ方法
トランザクション処理	トランザクション処理は限定的処理が実行可否を判断	NoSQLはトランザクション処理が実行出来るものもあれば出来ないものもある完全なトランザクション処理はない
データの堅牢性/一貫性	データの堅牢性/一貫性
スケールアウトの煩雑さ	高いスケーラビリティ	NoSQLはクラスタリングを想定して作られてるので高いスケーラビリティを保証できる
テーブルの運用負荷	クラスタの運用負荷	NoSQLはクラスタのサーバー台数が大きくなることでその運用負荷になる

キーバリューストア
- KeyとValueの単純構造
- メモリにすべて入るのでパフォーマンスが高い
カラム指向データベース
- カラム指向データ
- ログなどの大量データ解析向き
ドキュメント思考DB
- JSONなどのデータ構造に対応して複雑なデータモデリングを容易に実現化
グラフ指向データベース
- ノード同士の関係性を使用するDB

NoSQLで実現したいこと

NoSQLを使うことは目的ではない
実現したことがあるからNoSQLを使う
ユースケースとしては以下のイメージ
- どこまでスケールするかわからない基盤
- 低レイテンシ・高スループットが必要な基盤
- スケールするWebセッション管理
- Publish/Subscriptionモデル
- イベント処理
- JSONデータ格納
- ...etc
これらをどう実現するのかをNoSQLを選択される

AWSのNoSQLサービス

AWSのデータベースサービス

DynamoDB
ElastiCache
Neptune
RDS
Redshift

NoSQLが採用されているデータベースは？

Amazon ElastiCache

インメモリキーバリューストア
フルマネージド
- バックアップ等の運用はAWSが対応
ハイパフォーマンス
高いスケーラビリティ
- クラスタリングに対応している
Redis,Memcached
Amazonによる拡張(Amazon Redis)
- バックアップ改善
- FailOverの起動が早い
高可用性と堅牢性
- SecurityGroup
- VPC対応
- 暗号化
ElastiCache機能追加
- セキュリティ気機能の強化
  - Encryption-Intransit
  - Encryption-at-rest
  - Redis-AUTH
RedisClusterの対応
- Redis3.2でRedisClusterのサポート
- データを最大15シャードが使えて6TiB使える
- 最大2000万Read,450万Write
RedisClusterOnlineClusterResizing
- シャード数を変更するときにダウンタイムが発生していたが、本機能を使うことで動的にダウンタイムなしで増減できるようになった
- 構成例として下記の構成が可能になった
  - CWにてパフォーマンス劣化を検知
  - AWS SNS経由でLambdaを実行
  - ダウンタイム0でシャード変更

Amazon DynamoDB

フルマネージド
高速かつ一貫したパフォーマンス
高いスケーラビリティ
柔軟性
イベント指向のプログラミングも可能
高いセキュリティ
特徴
- 信頼性が硬い(管理が不要)
  - SPOFが存在しない構成
  - データは3箇所のAZに保存される
  - ストレージは必要に応じて自動的にパーティショニングされる
- プロビジョンドスループット
  - テーブルごとのReadやWriteに対して必要なスループットキャパシティを割り当てられる
  - RCU、WCUが存在し割り当てれれば料金がかかる
  - 別途金額が発生する
  - オンラインで対応が可能
- ストレージの容量制限がない
- 使った分だけ従量課金
- ディスクやノード増設作業は一切不要
機能追加
- バックアップ・リストア
  - ネイティブ対応している
  - 数百TBでもパフォーマンス影響無しで可能
  - PITRや継続的バックアップを実現
- DynamoDB Global Tables
  - 複数リージョンでデータを供したテーブルを作成可能
  - グローバルアプリケーションやDR対応に利用出来る
  - 東京は未提供
  - すべてのローカルにあるリージョンのテーブルに読み書きした物が非同期レプリケーションされる
- AutoSaling
  - キャパシティ設定(WCU,RCUなど)を動的管理
  - ターケゲット使用率と上限下限を設定することで必要なリソースに設定できる
- Amazon DynamoDB Accelerator(DAX)
  - DynamoDB全面に配置
  - マネージドかつAPI互換のキャッシュクラスタを配置して使えるサービス
- 読み込みの低レイテンシを実現
- TTL(Time To Live)
  - テーブルのItem有効期限を設定可能
  - ログを取得し続けたときにその分スループットが発生するので課金が発生する
  - TTLを設定することでログ保存期間を設定できる

Amazon Neptune

高速
- 高レベルのリレーションシップをミリ秒のレイテンシで問い合わせを実施できる
- 高信頼性
  - 3つのAZに跨る6つのレプリカをフルバックアップリストアを提供
- 簡単
  - GremlinとSPARQLによる簡単でパワフルなクエリを実行可能
- Apache TinkerPop&W3CrDFグラフモデルをサポート
グラフDBの得意分野
- 高度に連結された以下のデータが得意分野として挙げられる
  - ソーシャルネットワーク
  - レストランのレコメンデーション
  - 不正取引の検出

NoSQLのユースケース

キャッシング
- セッション情報などの頻繁アクセスしないものをオフロード
- DBへのクエリ結果をキャッシュしておく
- Amazon DynamoDB Acceleratorを使う
IoTソリューション
- IoTデバイスからIoTを吸い上げる
- ルールエンジンを利用してLambdaを実行してElastiCacheやDynamoDBへ保存する
  - 大量データはDynamoDBに保存
  - 低レイテンシはElastiCacheに保存
Pub/Subアプリ
- ElastiCacheはPub/Subとしても動作可能
- チャットメッセージサービスでPub/Subを実行
- リアルタイムリーダーボードなどで利用が可能
非同期アプリ - リアルタイム性の高いゲームにも使用が可能 - ElastiCacheのRedisSortedSetsを活用することで簡単に実現できる
グローバルアプリ
- GlobalTablesを活用することで世界中で同じテーブルにアクセスをかける
- 独自で持てば良いものは各リージョンで通常テーブルに持つ
非同期処理
- DynamoDBStreamsを使ってDBの変更内容を他サービスへ連携
- Lambdaが受け取ったデータをLambdaで他サービスへ処理を行う
時系列が必要なアプリ
- ホットデータとコールドデータをテーブルで分ける
- DynamoDBStreamsとGSIを活用して、非同期でホットデータをコールドデータに移行する
- TTLを活用することで使用しないデータを無効にする
デザインパターンの考え方
- RDBMSでのデータモデリング手法をNoSQLに当てはめても最適化出来ない場合がある
- 例えば正規化が該当する(RDBを上手く動かすベストプラクティスは全く別)
- データ連携にこだわらず実現したいこと(目的)にこだわる